home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001465_daemon _Mon Jun 28 07:11:58 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA12591; Mon, 28 Jun 93 07:12:00 MET DST
  3. Errors-To: sanders@bsdi.com
  4. Return-Path: <sanders@bsdi.com>
  5. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  6.     id AA12587; Mon, 28 Jun 93 07:11:58 MET DST
  7. Errors-To: sanders@bsdi.com
  8. Received: from austin.BSDI.COM by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  9.     id AA03645; Mon, 28 Jun 1993 07:35:10 +0200
  10. Received: from localhost by austin.BSDI.COM (5.67/1.37)
  11.     id AA27645; Mon, 28 Jun 93 00:35:06 -0500
  12. Message-Id: <9306280535.AA27645@austin.BSDI.COM>
  13. To: www-talk@nxoc01.cern.ch
  14. Subject: Re: browser execution 
  15. In-Reply-To: Your message of 27 Jun 93 20:53:00 PDT.
  16. Errors-To: sanders@bsdi.com
  17. Reply-To: sanders@bsdi.com
  18. Organization: Berkeley Software Design, Inc.
  19. Date: Mon, 28 Jun 1993 00:35:06 -0500
  20. From: Tony Sanders <sanders@bsdi.com>
  21.  
  22. > for some uses.  In particular, you need it if you want to repeatedly
  23. > run a program which outputs HTML (or MIME) and generally acts like
  24. > a server.
  25. ...
  26. > An executable MIME content type is good for "one-shot" executions
  27. > (like a "mail developers" link which runs a mailer), but it can't
  28. > cover the more dynamic semi-server case.  Why?  Because you need
  29. > a MIME document to back up each URL your server outputs that
  30. > refers back to the server.  This is fine with an HTTP server, but
  31. > for a browser-executed server it means having a file for every
  32. > link which defeats the purpose.
  33. SAS strikes again (server aversion syndrome :-)
  34.  
  35. FYI: Here is how using content-type might work for your example of a
  36. pseudo-newsreader (using a server of course).
  37.  
  38.     <A HREF="http://server/rn.html">drink me</A>
  39.  
  40. on selection returns the document:
  41.  
  42.     content-type: application/x-csh
  43.     ... whatever you wanted rn.html to do
  44.     ... links can look like <A HREF="http://server/article/####">read me</A>
  45.  
  46. http://server/article/#### returns:
  47.  
  48.     content-type: application/x-csh
  49.     ... whatever you wanted rn.html to do with the #### argument
  50.  
  51. So I argue we should figure out to have the browser talk to a local server
  52. rather than figure out how to encode arbitary commands in the URL.
  53.  
  54. My reasoning:
  55.   o Browsers cannot change on a whim, because for the Web to be truly
  56.     useful to the user community at large all browsers must support the
  57.     **same** set of features (to a large extent anyway).
  58.   o Therefore we **must** have a definition for the browser that is simple
  59.     and complete such that any features you might ever want can be done
  60.     in a server.
  61.  
  62.     So why the SAS that seems to be so prevalent?  Instead of hacking
  63.     things into the browser we should be looking for ways to extend the
  64.     browser such that servers can do those tasks, but everyone seems to
  65.     be heading the opposite direction.  Maybe this is something we
  66.     can take up at the workshop (what should go in the server and what
  67.     should we build-in to the browser).
  68.  
  69. I'm not a purist or anything, I think it's fine if we want the browser to
  70. support things like gopher and ftp directly but at some point we are going
  71. to have to draw the line if we want most browsers to support a common
  72. set of features (even <IMG> is a good example of this problem).
  73.  
  74. --sanders